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Abstract — Planning and scheduling for space operations 
entails the development of applications that embed intimate 
domain knowledge of distinct areas of mission control, 
while allowing for significant collaboration among them. 
The separation is useful because of differences in the 
planning problem, solution methods, and frequencies of re- 
planning that arise in the different disciplines. For example, 
planning the activities of human spaceflight crews requires 
some reasoning about all spacecraft resources at timescales 
of minutes or seconds, and is subject to considerable 
volatility. Detailed power planning requires managing the 
complex interplay of power consumption and production, 
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involves very different classes of constraints and 
preferences, but once plans are generated they are relatively 
stable. A prototype application has been developed that 
separately supports Crew planning and Power planning for 
the International Space Station (ISS). Domain requirements 
have been modeled in a significant level of detail, and 
loosely-coupled integration has been demonstrated in a 
realistic scenario. The integration is enabled by 

implementing a generic collaboration architecture that can 
be used to coordinate the work of any number of planning 
domains. The architecture is used to integrate two different 
planners employing different underlying algorithms and 
data structures, by means of mapping the overlapping facets 
of the plans. 
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1. Introduction 


AI Planning and Scheduling technology is increasingly being used to support operations in the control center for space 
missions. A significant technology deployment challenge is in developing domain models and application architectures that 
naturally map to the processes already established by the mission control organization [1]. Without such arrangement, the 
technology is unlikely to be adopted. Mission operations planning for the International Space Station (ISS) is a perfect 
example of this situation; due to the complexity and breadth of the requirements for mission planning, responsibilities are 
split into a number of flight control disciplines [2] summarized in Figure 1. 

Each discipline has very different domain description requirements and spheres of responsibility. At the same time, a large 
amount of communication among flight controllers is necessary since decisions taken by one discipline may affect one or 
more of the other disciplines 1 in significant ways. As a simplified example, consider a collision avoidance maneuver, 
typically caused by orbital debris on the ISS' path. In addition to trajectory adjustments overseen by the Trajectory 
Operations Officer (TOPO), the solar arrays must be locked, thus reducing power generation, managed by the Power Heating 
and Lighting Control Officer (PHALCON). If this situation persists, some powered payload or crew activities may have to be 
delayed by the Ops Controller (Ops) until there is enough power. If there was an Extra- Vehicular Activity (EVA) scheduled, 
its related activities may have to be adjusted, and so on. 

The “Automation for Operations” (A40) project at NASA develops advanced automation technology for infusion into 
human space-flight mission operations. As part of this project, we have created distinct planning software applications that 
support the Ops and PHALCON disciplines, as well as collaborative planning between them. These applications map 
naturally to the current discipline boundaries and collaboration model. Present day operations involve coordination between 
PHALCON and Ops controllers by a combination of voice loops, manual plan modification and validation, and manual 
integration of plan changes between disciplines. Our advanced prototype improves on the state of the art in several ways. 
First, by enabling the flight controllers to use automation to rapidly modify plans, flight controllers gain flexibility and 
improved responsiveness to unpredictable events during operations. Second, by employing model-based planning 
technology, operational tools can be modified more efficiently as the rules change (a frequent occurrence due to changes in 
equipment configuration and flight software). Finally, by providing tools that seamlessly transmit information between 
disciplines, coordination between flight controllers is simplified, thereby decreasing conflict on voice loops and streamlining 
the operations process. 



Discipline 

Brief Description 

Flight Director (Flight) 

Primary decision-making authority for station operations. Leads flight 
control team. 

Assembly and Checkout 
Officer (AGO) 

Integration of assembly and activation tasks for all ISS systems and 
elements. 

Attitude Determination and 
Control Officer (ADCO) 

Works in partnership with Russian controllers to manage the station's 
orientation, controlled by the onboard Motion Control Systems. Calculates 
future orientations and maneuvers for the station. 

Communication and 
Tracking Officer (CATO) 

Management and operations of the U.S. communication systems, 
including audio, video, telemetry and commanding systems. 

Environmental Control and 
Life Support System 
(ECLSS) 

Responsible for the assembly and operation of systems related to 
atmosphere control and supply, atmosphere revitalization, cabin air 
temperature and humidity control, amonq other areas. 

Extravehicular Activity 
Officer (EVA) 

Responsible for all spacesuit and spacewalking-related tasks, equipment 
and plans. 

Onboard. Data, Interfaces 
and Networks (ODIN) 

Responsible for the U.S. Command and Data Handling System, including 
hardware, software, networks, and interfaces with International Partner 
avionics systems. 

Operations Support Officer 
(OSO) 

Console operator that is charged with those logistics support functions that 
address on-orbit maintenance, support data and documentation, logistics 
information systems, maintenance data collection and maintenance 
analysis. 

Power, Heating, Articulation, 
Lighting Control Officer 
(PHALCON) 

Manages the power generation, storage, and power distribution 
capabilities. 

Robotics Operations 
Systems Officer (ROSO) 

Responsible for the operations of the Canadian Mobile Servicing System, 
which includes a mobile base system, station robotic arm, station robotic 
hand or special purpose dexterous manipulator. 

Thermal Operations and 
Resources (THOR) 

Responsible for the assembly and operation of multiple station 
subsystems which collect, distribute, and reject waste heat from critical 
equipment and payloads 

Trajectory Operations 
Officer (TOPO) 

Responsible for tbe station trajectory. The TOPO works in partnership with 
Russian controllers, ADCO, and the ITS. Space Command to maintain 
data regarding the station's orbital position. TOPO plans all station orbital 
maneuvers. 

Operations Planner (Ops) 

Leads the coordination, development and maintenance of the station's 
short-term plan, including crew and ground activities. 

Ground Controller 

Responsible for MCC systems and coordination with the ground to space 
communications network. 


Figure 1 . ISS Mission Control Disciplines 

Collaboration is enabled by an architecture developed specifically for coordinating disparate planning systems. This 
architecture provides translation and synchronization mechanisms that allow the automated planners for each discipline to 
use different planning technologies and be as complex and domain-specific as necessary. Specifically, the planners may each 
use different domain models and representations, but may still communicate essential state and intention with others. As a 
result, automated planners are given access to information that is necessary in making decisions for their discipline, but may 
be owned by other disciplines. 

Planning ISS operations is a highly collaborative process that requires numerous iterations and negotiation among the NASA 
disciplines and with International Partners (IPs). The current approach is already putting great demands in terms of training 
and time needed to generate and coordinate plans on the human planners, automation is greatly needed to alleviate their 
burden. 

The paper organization is as follows: first, we describe the domain requirements for both the Ops and PHALCON 
disciplines, and the planning applications developed to address their needs. Next, we describe at a domain level, a scenario 
that requires collaboration between the 2 disciplines, then we describe how this collaboration was implemented using the 
A40 architecture. We conclude by pointing out current and future directions for this work. 

2. Crew Planning 

The Station Ops Planner leads the coordination, development and maintenance of the station's short-term plan, including 
crew and ground activities. The plan includes the production and uplink of the On-Board Short Term Plan (OSTP) and the 
coordination and maintenance of the on-board inventory and stowage listings. Planning for an ISS increment (the time period 
a specific crew remains on the ISS) is done in several iterations with an increasing degree of granularity : 




Product 

Description 

Timinq 

Ground Rules and 
Constraints (GR&C) 

First effort to respond to the 
priorities outlined for the 
increment 

Development starts 8 
months before the 
increment 

On-Orbit operations 
summary (OOS) 

First plan to address priorities for 
the increment. Covers entire 
increment 

Development starts 5.5 
months before the 
increment 

Weekly Lookahead plan 
(WLP) 

More realistic representation of 
the OOS, more detailed 
constraint modeling 

Generated 3 weeks 
before the increment’s 
day is executed 

Short Term Plan (STP) 

More realistic constraint 
model ing. Inductions ofr 
execution are included 

Generated 2 weeks 
before the increment's 
day is executed 

On-Board Short Term 
Plan (OSTP) 

This is the plan that is uplinked to 
the ISS and executed 

Generated 1 week 
before the increment's 
day is executed 


Figure 2. Planning products for an ISS increment 

The crew will typically stay as close as possible to the OSTP, although unforeseen repairs, medical procedures and other 
similar urgent conditions normally arise during each increment. Any changes to the OSTP are handled through a Planning 
Product Change Request (PPCR), which requires approval of at least 3 people. 

For our tests we concentrated on the OSTP, but the same approach can be used to support the other time intervals. 


Activities and Constraints 

All of the activities and constraints for the increment are documented in detail in the GR&C and other supporting documents 

that provide payload and other, discipline-specific details [3], a very brief summary of the most important elements for Crew 

Planning is provided below. 

• The crew plan has a stable backbone in the form of a pattern that repeats daily : the day starts with a post-sleep period 
which lasts 90 minutes and includes personal time, breakfast and preparation for the day. Next is the daily planning 
conference (DPC) which takes about 15 minutes, this is a brief conversation with mission control to go over the plan for 
the day. In the middle of the day there is a 1 hour block for lunch, which is taken together by the crew if possible. At the 
end of the day there is a pre-sleep period of 120 minutes that includes debriefing for the day, dinner and personal time. 
The day ends with a 8.5-hour sleep period. Given the negative effects of low-gravity on the human body, crew members 
are required to exercise for 2.5 hours every day. There are several pieces of exercise equipment on board and each crew 
member has some latitude to choose the kind of exercise, time of the day and intervals (a single block vs. 2 separate 
sessions). 

• Beyond the daily pattern, there are a number of activities that repeat more or less regularly, like medical conferences and 
some maintenance activities. 

• Many payload activities (science experiments) require involvement from the crew and also entail some temporal and 
resource constraints, including power. 

• There are complex procedures for certain maintenance or repair operations and for EVAs (space walks). These typically 
contain a number of sub-activities with associated temporal and resource constraints. 

• When a spacecraft (shuttle, soyuz) is docked to the ISS, joint operations with the visiting crew require a temporary change 
of structure (ISS may have to work in shifts for a while to provide around-the-clock coverage). There are also a number of 
complex procedures (docking, undocking, joint EVAs and others) that are associated with this mode of operation. 


Planning Goals 


The main goals are safety and feasibility. Ops planners want to always have plans that are executable and that do not violate 
any of the medical or procedural constraints. 




The other major objective is to maintain a good quality of life for the crew. This involves things like stability of the schedule, 
respect of crew rest periods, exercise equipment preferences, and personal time. In addition to the previous objectives, it is 
desirable to achieve as many science goals as possible within each increment. 

Changes in the power profile can potentially affect any of the crew activities, however, the Ops planners only need to know a 
summarized profile (for discrete named power levels, how much power is available and for how long), whereas the detailed 
computation and management of power is the responsibility of the PHALCONs, which is where we turn our attention next. 


3. Power Planning 

The Power Planning responsibility within the PHALCON discipline is charged with managing the generation, conditioning 
and supply of power to the ISS (the Provide Power function), as well as coordinating the reconfiguration of the electrical 
power system (the Control EPS function). Matching the planning focus of the crew planner, our tests concentrate on the 
OSTP horizon of about a week in advance, where dynamic planning is most relevant. 
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Figure 3. Power Planning function in Context 

The main source of control inputs to Power Planning is the Attitude Control discipline (ADCO). ADCO provides constraints 
on station attitude as well as array pointing angles, which directly affect the available power generation. From this varying 
supply, the power plan must choose how to serve the various power loads scheduled in the Flight Director's consolidated 
plan (which includes Crew Planning inputs along with contingency activities). Excess supply may be stored to (and excess 
load may be drawn from) the station's battery array, within hardware and flight rule constraints. The interaction of Power 
Planning with other disciplines is summarized in Figure 4. 



Item 

To / From 

Description 

Inputs 

Incident Sunlight 

Sun 

Direct sunlight on solar arrays. 

Control Data 

IP S MSC Power Data 

PRO. PHALCON 

Trending data for future planning 

STP/OSTP 

Flight Director 

Long-Term activity profiles for baseline 
planning. 

Body/Celestial State 

ADCO 

Station attitude and ephemeris. 

Sun Lighting Events 

ADCO 

Day /Night on ISS as a function of orbi. 

Beta Angle Summary 

ADCO 

Solar Beta Angles at ISS 

State Variable Table 

ADCO 

Ephemeris for ISS 

Joint State 

ADCO 

Solar Array Joint angles 

Event Attitude Summary 

ADCO 

Required station attitude for given 
events/epochs Desired angles for solar 
arrays. 

EPS Status 

EPS 

Telemetry from power generation/conditioning 

Outputs 

Power Availability 

Flight Director, Crew 
Power Planning 

Current Base Supply 

Battery SOC Profiles 

Flight Director 

Projected Battery SOC based on plan 

Power Usage Profiles 

Flight Director 

Projected Power Usage /Mar gins based on plan 

Commands 

EPS 

Commands to control the EPS 

System Power 

Crew Power Planning 

Conditioned power to crew loads 






Figure 4. Power Planner Interfaces and Descriptions 


Activities and Constraints 

The backbone power plan consists of a periodic response to changing solar availability. In station orbit, the sun rises every 
92 minutes and illuminates the station for approximately 60 minutes at constantly changing angles. In order to maximize the 
power generation from the solar arrays, the array assemblies are placed in an auto-track mode when the sun is visible. When 
the station enters eclipse, the arrays are stowed to a drag-reduction bearing. This diminishes the atmospheric drag on the 
station and saves on re-boosts by the shuttle. During the eclipse periods, the station operates frilly from the energy stored in 
its battery array. The battery's state of charge is tracked in detail as a metric resource. When the sun rises once more, the 
arrays are again steered to auto-track the sun and power generation resumes. 

Crew and station operations are layered on top of this periodic plan, and may force the arrays to be configured in a mode 
contrary to backbone. For example, the array steering must be locked out during extra-vehicular (EVA) maintenance of the 
station for the safety of the astronauts. Each possible contingency activity is modeled along with its array pointing 
requirements, and the array mode is tracked as a state variable of the system. Transition Activities are taken by the power 
planner to effect any of the legal mode transitions and reconfigure the solar arrays as appropriate to the specific situation. 
Prime activities and the transition matrix are presented in Figure 5. 

The power plan may also explicitly call for load shedding on the station's EPS. This occurs if the battery reserves fall below a 
flight-rule constraint, and ensures that the station and crew have ample power in case of emergency. The current constraint is 
approximately 85% of the battery's full state of charge. After the battery reserves have been replenished, the power plan can 
call for previously shed loads to be reinstated. 


Planning Goals 

Safety and survivability are the primary goals of the power plan. The power plan must at all times maintain an emergency 
margin to protect the crew in the event of a station failure. A secondary objective is to fully supply all of the station 
experiments and extraneous loads, and also to reduce aerodynamic drag of the station. 

Station operational goals (EVAs, collision avoidances, water dumps, etc) are mandated to the power planner, which in turn 
publishes a power profile summary to other disciplines. This summary includes a named power mode indicating the level of 
support offered by the EPS for each time period within the plan horizon. 



Prime Actitivies 

Nominal Activities 

Sun 

ISS in sunlight. Arrays track sun(with offset if commanded). Station at 
default attitude. Best power performance 

Eclipse 

ISS in eclipse. Arrays at “edge on" angle to minimize drag. Station at 
default attitude 

Dock 

ISS at docking attitude. Arrays configured for best comm. Duration 1.5-3 
hrs 

EVA 

ISS attitude for EVA. Arrays configured for EVA safety + comm. Duration 
4-8 hrs 

Dump 

ISS attitude to Dump Waste / Condensate Water. Duration 1-2 orbits 
(1.5-3 hrs) 

Off-Nominal Activity 

ColAv 

Collision Avoidance activity. ISS assumes attitude to do an orbit-change 
in order to avoid an object i 



Figure 5. Planner Prime Activities and Transition Activity Matrix 


4. Inter-discipline Integration Scenario 

As can be seen from the descriptions above, understanding and modeling each discipline requires a considerable amount of 
effort. After the discipline-specific domain models are in place, we are ready to dive into interactions between them. 

Changes introduced by PHALCON will typically affect many of the other disciplines, in fact, this was one important reason 
to include that discipline in our tests. On the Crew Planning side, most activities do not consume enough power to warrant 
power planning consideration when they are changed. However there are some exceptions, such as the operation of the 
robotic arm. Other activities that may trigger reaction from PHALCONs, are activities that limit power production, such as 
collision avoidance maneuvers and water dumps, which require the solar arrays to be locked to protect them from damage. 

In our scenario, a water dump is part of the nominal plan (OSTP), however, it is not uncommon for this activity to take 
longer than expected since the evacuation rate may vary. If a water dump activity is extended beyond its original duration, it 
is normally extended for at least the duration of one orbit (92 minutes), during this time the solar arrays are locked to prevent 
damage. On the power side, one of the flight rules is to maintain the battery levels to at least 85% capacity; whenever the 
battery is drained below that level, the EPS switches from nominal mode to what is called “core” mode, and power for some 
non-essential sub-systems may be interrupted until the battery goes back above the required charge level. 







Figure 6. Inter-discipline integration scenario 

To test communication initiated from the Crew planner we extend the duration of a water dump activity in the crew plan. 
(See Figure 6) The power planner receives the new information and flags the possible violation of the minimum 85% battery 
level given the new duration. The PHALCON controller is then able to rely on the Power planner to automatically fix the 
plan for the solar arrays and produce the new power profile. 

However, the new situation cannot be handled without going into core mode for a short period of time. This change is 
propagated to the crew planner, where some of the science payload activities are on a power string that is disabled when the 
EPS enters core mode. This causes the Ops controller to see conflicts on the activities planned for the crew. The controller 
may in turn rely on the automated Crew Planner to fix the problems, or do it manually. 

In our scenario we stop at this point with consistent plans on both planners, but the coordination could continue, especially if 
other disciplines are involved. This process is currently performed with some IT support, but without any significant 
planning and scheduling technology. The visibility and agility provided by the automated planners should be of great benefit 
to the controllers. 


5. Architecture for an Integrated Solution 

A collaboration infrastructure was developed to allow for the efficient exchange of essential plan information among the 
disparate discipline-specific planning engines. A coordination agent is externally attached to each participating planner (see 
Figure 7), and each agent is concisely configured to translate events between the planner it represents and the other 
coordination agents it connects to. The coordination scheme owes a philosophical heritage to the ShAC multi-agent 



coordination system [4], but was redeveloped from the beginning to support various planning architectures for the agents. In 
particular, the exchanged plan entities do not themselves describe how an action or resource is to be considered, just that it 
exists with specific values. The separate domain planners decide independently how to interpret and act on the information. 
For example, a PHALCON controller will consider the details of a solar array maneuver and its effect on generated power, 
but the EVA controller need only be assured that the arrays are locked during a spacewalk. 



Figure 7. Coordination Architecture 

This separation of system expertise has several benefits : 

• It directly reflects the administrative divisions of the humans using the aggregate system. 

• Specific domain models are much easier for experts to articulate, and thus encode within a planning system of choice. 

• A different planning tool can be used for each domain. 

• The problem size for each domain is considerably smaller than if all constraints were considered within a single planning 
context. 

The division of expertise comes with costs however. The most notable is handling communication among different agents 
when coordinated action is called for. Fortunately, as in many domains, the ISS utilizes fairly coarse-grained coordination, 
and thus communication cost is limited to a small set of mission-wide actions. 

The set of actions that a cognizant discipline controller publishes, as well as those external actions it needs to coordinate on, 
are listed in a small file that describes the mapping of identifiers used by each agent. The collaboration infrastructure uses 
this mapping to generate just those updates that are needed to maintain the consistency of the aggregate system. Possible 
updates include creation, deletion, and modification of planned actions. These updates are sent to agents that are interested in 
the subject action. Resource and timeline changes are propagated via coordinated value modification actions. 

Note that the details sent to each agent depend on their use of the action/resource: the PHALCON controller has full watt- 
hour detail on every power draw, but the Ops system only gets updates when the power system expects switches between 
“core” and “nominal” modes. 
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Figure 8. Model mapping in the Coordination Agent 

The mapping language for the coordination agent is presented in Figure 8. The “Coordination Model” box contains a snippet 
from our demonstration that includes all the elements in the language. A schema element describes a specific part of the 
domain models that must be synchronized, in this example, the “reduce_payloads” activity in the Power domain will be 
represented by corresponding “CoreMode” activities in the Crew domain. Each schema element contains role and 
parameter elements. Possible planner roles are manager (if the planner publishes information) or user (if the planner 
consumes information). Each schema element must contain at least one manager role and one or more user roles. Each role 
element contains template and local elements. The template element specifies the name of the planner, and the activity type 
to be synchronized, in our example, the element “template powenreducedjpayloads” means that for the planner called 
“power” we will monitor instances of the activity type “reduced_payloads”. Finally, the parameter element from schema 
and the local element from role provide a mechanism to specify how activity parameters are mapped from one domain to 
another. 

The Coordination Agent reads this description and uses CORBA to communicate with the planner it represents before the 
other Coordination Agents. Each planner must therefore support a small CORBA interface and register with the CORBA 
naming service using the same name specified in the template element described above. 

The CORBA interface contains only 4 methods (method signatures are abstracted for brevity's sake) : 

• getChangesQ : Returns a data structure specifying all activities added/deleted/changed inside the planner since the last 
time this method was called. This is used by the coordination agent to get changes from the planner and push them out to 
other interested coordination agents. 

• add/delete/changeActivities(Collection<Activity> acts) : these 3 methods are used by the coordination agent to push 
changes coming from other coordination agents into the planner. 

A common agent code base sits on top of this CORBA interface and manages all of the planner’s coordination. Thus the 
planners themselves need not have any concept of coordination. 

As can be seen in Figure 8, the Coordination Model maps directly to elements inside each of the domain models. The 
coordination mechanism although complete is not very flexible in terms of mapping different semantics or data granularity 
levels. For this approach to work correctly and efficiently it is important to write domain models that are amenable to it. 
Currently we take advantage of the sophisticated modeling mechanisms available in both EUROPA and ASPEN to provide 
appropriate placeholders for coordination (this takes care of semantic differences) and to aggregate/disaggregate activity 
information from each domain model (this takes care of data granularity differences). Fortunately, this is natural thing to do 



since currently the human planners perform similar kinds of operations in order to be able to talk to other disciplines. 
However, in terms of implementation, this functionality could eventually be part of the coordination agents to keep the 
models free of elements needed only for coordination purposes. 

Finally, unlike the ShAC system, our current demonstration does not utilize any structured coordination protocols, instead 
each agent simply notifies the others of updates it has affected. Ownership of modeled actions is reflected directly in the 
domain models of each discipline (eg the power controller simply does not have permission to add crew sleep activities). In 
expanded systems, this peer-to-peer interaction is expected to be replaced with protocols akin to ShAC’s master-slave or 
round-robin rights dispatching. 


6. Implementation 

Crew and Power planning applications were created using EUROPA and ASPEN, two different planning platforms 
developed at NASA, whose respective strengths matched well with their assigned domain. The coordination architecture was 
implemented in C++ and CORBA was used as the middle-ware for inter-process communication. The solution was deployed 
and demonstrated on Linux workstations. 

This implementation was used to automatically generate an OSTP to cover 4 days of operation for a 3-member crew, using 
information about payloads and activities from a previous ISS increment. Two way communication between the planners 
was demonstrated by manipulating activities in both planners and using the other planner to automatically flag new 
problems in the plan and assist the corresponding discipline in solving them. The entire system was validated in 
demonstrations at NASA's Johnson Space Center given to controllers from both disciplines. The controllers commented 
favorably on the system's applicability and expressed support to continue to develop this approach to cover more of the 
planning process. 


Crew Planning application 

The Crew Planning application was created using Ensemble [5] for the UI and EUROPA [6,7] as the planning engine. This 
same combination is already being used in several NASA missions such as MER and Phoenix [8]. 

The Crew Planning model includes all of the main domain elements outlined above (daily plan backbone, medical 
conferences, maintenance and payload activities). The Power Profile is visualized as a high-level timeline that only contains 
“core” and “nominal” states. 


The user can manipulate the plan by adding, changing and removing activities. The planning engine provides constraint 
checking, constraint violation explanation and automated conflict resolution for a number of temporal and resource 
constraints. 




Figure 9. Crew Planning Application 


Power Planning Application 

The ASPEN [9] general automated planning system was used to provide power discipline planning. ASPEN has been used 
by several missions for ground-based operations planning, as well flown on board for real-time planning capabilities [10,1 1]. 
The ASPEN system uses a custom JAVA-based GUI interface to facilitate human interaction with the automated planner. 



Figure 10. Power Planning Application 

The power discipline model is encoded in a textual input file, and is developed by consulting both human experts and ISS 
procedure documentation. The plan domain includes treatment of exogenous sunrise and sunset events, crew-initiated station 
maneuvers, battery and bus resource monitoring, and generates appropriate power system command actions to steer the solar 
arrays and manage dynamic EPS loads. The plan is presented to the user in Gantt-chart summary form, from which they may 
inspect the solution, examine plan conflicts, hand tweak event timing and resource usages, and call upon the automated 
planning engine to assist. 


7. Conclusions and Future directions 


Generating an ISS increment plan is a highly collaborative process that requires numerous iterations and negotiation among 
the NASA disciplines as well as with international partners to converge to a consistent plan. The current tools to support this 
process leave a lot of the burden of constraint checking, contingency evaluation, optimization and integration to the human 
planners. This is already an overwhelming burden [12,13] and it will only get worse as the ISS grows and the role of 
international partners becomes increasingly prominent. The training and communication costs, as well as time delays make it 
very hard to scale up the current process to continue to do increment planning as the ISS grows and other missions need to be 
supported by the same personnel. 

We have demonstrated how a significant part of this burden can be transferred to automated planning tools in a way that 
supports the organizational boundaries and expertise that are currently in place. We have created detailed applications to 
support the Ops and PHALCON disciplines and have demonstrated through a realistic scenario how required communication 
between the two can be carried out. The integration architecture and approach is domain-independent and can be scaled up to 
support any number of disciplines, so that it could eventually used to support the entire planning process. 

There are numerous avenues that can be pursued to build on this work and improve support for space mission planning and 
control, below we list some of the most promising ones (some of these are already being actively pursued by the same team): 

• Evaluation of alternative plans would be very useful. Our application only allows for coordination of a single plan. Out 
entire infrastructure (EUROPA, ASPEN, and the integration architecture) allows for the manipulation of multiple plans, 
but this capability needs to be exposed at the application level to the end user. 

• Integration with Procedure Execution and real time telemetry would be a great addition to support real-time re-planning. 

• At the application level, better support for negotiation would be very useful, examples of this are better notification and 
explanation of events coming from other disciplines, logging of negotiation decisions and iterations, etc. 
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